home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 3⁄23⁄90 / 0928-Printing Response-Mar90 < prev    next >
Encoding:
Text File  |  1990-03-23  |  3.2 KB  |  65 lines  |  [TEXT/GEOL]
  1. Item    6786355                         19-March-90        10:41PST
  2.  
  3. From:   PILLAR.CORP                     Pillar, Chris Ovard,PRT
  4.  
  5. To:     AUST0134                        Jam Software Sydney,IVR
  6.         MADA2                           MacApp Dev Assoc, Curtis Faith,IVC
  7.  
  8. cc:     MACAPP.TECH$                    MacApp Technical
  9.  
  10. Sub:    Printing Response
  11.  
  12. This link is in response to several recent links about printing in MacApp.
  13. Sorry for my delay in responding but deadlines loom ahead...
  14.  
  15. To Tommi of Kopfwerk, Austeria:
  16.  
  17. You mention trouble printing on the LaserWriter.  Since the LaserWriter is a
  18. PostScript printer, it doesn't fully support QuickDraw.  In particular I know
  19. that it doesn't support all region manipulations.  For example, when you resize
  20. a view, MacApp invalidates some region of the view (TView.Resize).  If you
  21. resize a view while you are printing you are very likely to crash.  The only
  22. documentation of the LaserWriter limits that I know of are in Inside Mac
  23. II-156.
  24.  
  25. Your second question is about offseting your headers when printing a grid view.
  26. Here is how I resolved the problem.  I have a subclass of TView,
  27. TAdornSuperView, that holds all of the other views that I want to draw in
  28. AdornPage.  This subclass exists primarily to deal with focusing, it is similar
  29. to a TWindow in that it knows how to focus itself into QuickDraw coordinates.
  30. Anyway my header view is a subview of this TAdornSuperView during printing.
  31. Below is a fragment of my AdornPage method:
  32.  
  33.     topLeftCorner := {calculations to find position on page for header}
  34.     topLeftCorner.h := topLeftCorner.h - fViewedRect.left;
  35.     headerView.Locate(topLeftCorner.h, topLeftCorner.v, FALSE);
  36.     ...
  37.     adornSuperView.DrawContents;
  38.  
  39. The local variable topLeftCorner is a VPoint.  The code calculates the position
  40. of headerView in the adornSuperView.  First what you would think of as the
  41. "normal" position of the view is found.  fViewedRect contains the part of fView
  42. that the standard print handler is printing on the current page.  Therefore
  43. subtracting the left edge of that view from the position of the header view
  44. effectively offsets the view on each subsequent vertical strip of the printout.
  45. Since the clipping rectancgle prevents us from drawing outside the page what
  46. you get on the printout is exactly what is needed on wide printouts.  After
  47. coding this it occured to me that the TScroller class could probably be used to
  48. accomplish much the same thing.
  49.  
  50. To Curtis Faith:
  51.  
  52. I think the above ideas will be of some use to you in printing the logos you
  53. talked about on 3/16/90.  It will allow you to print the view in different
  54. spots on each page (the current page is always available in fFocusedPage).  As
  55. far as printing only parts of the view on different pages you might try laying
  56. out your view so the unneeded parts get clipped as above.  I'm not sure if that
  57. will work since I don't know where the view is coming from and its layout.
  58.  
  59. You are right about the print handler setting up the clipping region so the
  60. desired part of the view is printed on each page.  As I understand the
  61. coordinate translation from the view to the printed page, there really isn't
  62. any.  The fPageAreas data is defined in such a way that 0,0 of the view being
  63. printed and 0,0 of the grafPort correspond.
  64.  
  65.